Subject: Various SDLC

From: "David Miller (254-5752)" <[email-masked]>
Date: Thu, 13 May 93 15:58:12 EDT

1)  SDLC end-to-end

For SDLC end to end, the following scenario could be used:

3745               6611                 6611                PU 2.0
                              .
                              .
                              .
                        topology xchg
                     *<----------------->*
                              .
                              .
                              .
                      CURFRAME
                     *------------------>*
                                 ICRFRAME
                     *<------------------*
                      RESPACK
                     *------------------>*
                              .
                              .
                              .
SNRM                   CONTACT                           SNRM
-------------------->*------------------>*------------------->*
                  UA |                                    UA  |
<--------------------+        CONTACTED  *<-------------------+
                     *<------------------*
RR                                        RR
-------------------->*                   *------------------->*
                  RR |                                     RR |
<--------------------+                   *<-------------------+
                    I              IFRAME                    I
<--------------------*<------------------*<--------------------
|                RR                      |                 RR
+------------------->*                   +-------------------->

The new flow "topology xchg" (TX) is not currently in RFC 1434, nor
is it implemented by IBM.  However, we think it is a good idea to
cut down the number of excessive broadcasts and to limit customer
configuration.  Without it, both 6611s would have to define MAC
addresses for their respective SDLC stations.  One side at a minimum
would have to know the MAC address of the other.  This side would
simulate the receipt of a TESTFRAME and send out the CURFRAME.
With TX, the routers, during initial bringup, could
exchange topology information detailing permanent resources
(such as SDLC stations) or non-permanent resources (such as LAN
devices.)  This has several advantages:
  1.  With the current scheme, MAC addresses would have to be
      defined for both the 3745 and the PU2.0.  With a flat MAC
      address space, management of all these addresses can be
      horrendous.
  2.  SDLC devices could now be locally defined by something other
      than MAC addresses, allowing the use of link/address pairs
      or names to uniquely identify SDLC stations.
  3.  Use of topology information to preload any routing cache increases
      its hit rate.  The higher the hit rate for the
      routing cache, the lower the numbers of broadcast CURFRAMEs and
      higher the numbers of directed CURFRAMEs.

2)  Blue vs Gray

This is the original terminology used to distiguish which DLSw
started the circuit.  "Blue" initiated the circuit upon receipt
of a TESTFRAME and sent a CURFRAME to the "gray" partner DLSw.

3)  Flow Control

Yes, ENTER_BUSY and EXIT_BUSY could be viewed as having redundant
function to the pacing mechanism.  However, using only IPM and pacing
bits in the current incarnation does not allow the DLSw recognizing
an RNR condition to immediately react and inform the other side.
It must instead withhold a pacing response.  This means that the
DLSw must be capable of buffering at least a window's worth of
frames per circuit.  Once the other side has sent a window's worth
it could cease to send frames and begin a local RNR condition.
With ENTER_BUSY and EXIT_BUSY, the intent is to provide some
mechanism to proactively cease traffic sooner than a window's worth
of frames.  The CWI could be used in this situation piggybacked on
an IPM if no IFRAME is available.  What do you think?

4) Segmentation and reassembly

Currently 2052 is an implementation size limit for frames.  This is
the maximum that the bridge into the 6611 can handle.  DLSw does not
do any segmentation across the WAN.

5) LPDA

Currently the 6611 does not handle LPDA.  Given the following
picture, any ideas on how to make LPDA work??
                                                    Modem--PU2.0
                                                   /
3745 -- Modem --/                                 /
               /-- Modem -- 6611 ... 6611 -- Modem--Modem--PU2.0
                                                  \
                                                   \
                                                    Modem--PU2.0

David Miller

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Fri, 14 May 1993 15:50:00 +0000

>               /-- Modem -- 6611 ... 6611 -- Modem--Modem--PU2.0
In the LPDA2 frame there are two imbedded addresses, A1 and A2.  The A field
of the frame always carries FD so that is meaningless.  A1 indicates the
address which is recognized for frames coming from the DTE interface, and A2
is the address recognized for frames coming from the analog (line) interface.
Each diagnostic modem has a unique address.  For the purpose of this exercise
lets us say:

                                                     Modem--PU2.0
                                                    / 04
 3745 -- Modem --/                                 /
          01    /-- Modem -- 6611 ... 6611 -- Modem--Modem--PU2.0
                     02                        03  \  05
                                                    \
                                                     Modem--PU2.0
                                                      06

The line is defined to the NCP with TAILING= and some other parameters which
permit describing the topology of the link.

To perform a diagnostic on modem 5, the NCP would send out an LPDA2 frame
with A2=05.  This frame is copied by modems 01, 02, and 03 who all do not
recognize the target address.  Modems 04 and 06 also see the frame, because
they are on the same line as 05, but the address does not match them either.

In QLLC the only requirement is to add the ability to carry a qualified
packet with a command code indicating LPDA2, which is easy to add to the
architecture as long as both ends understand it.  A separate VC is used
associated with address FD at both ends of the network.  The remote PAD also
has to understand that LPDA frames can have a very long running time, and
that, particularly on a multipoint line, it should not time-out the request
for at least a minute.

In DLS it is not quite as clear how to handle this.  For one thing,
obviously, you can't handle this if either end is a LAN.  Since modem 03 is
shared among all of the attached stations, it does not make sense to use any
of their simulated MAC addresses.  Does that imply that you would have to
fudge up yet another phony MAC address, even though that MAC address would
never appear on any LAN segment, since this end to end testing would apply
only if BOTH ends were SDLC?  

If the host end is a LAN, which is always true at present, then there is a
product requirement, not specifically related to RFC1434, to be able to
initiate an LPDA2 test on the attached [possibly multipoint] line.  Is there
a logical way to do this with SNMP?  Should the router initiate an LPDA2 test
automatically on certain error thresholds? Should there be MIB structures for
the results of these diagnostics?